Context and Interception : .NET Component Services

Figure 1. App domains and contexts

In .NET, the context is the innermost execution scope of an object. Components indicate to .NET which services they require using special context attributes. All objects in the same context are compatible in terms of their component services requirements, and .NET doesn't need to perform pre- and post-call processing when these objects access one another. You can, therefore, define a context as a logical grouping of objects that rely on the same set of services. Calls into the context are intercepted to ensure that the objects always get the appropriate runtime environment they require to operate.

1. Contexts and Object Types

What if a component doesn't require any services? Why should it pay the interception penalty for cross-context access? To address this point, .NET objects are classified into two categories: those that care about component services and want to use them, and those that don't. By default, objects are context-agnostic and have no context affinity, which means they always execute in the contexts of their calling clients. Because such context-agnostic objects "jump" from one context to the next, they are referred to as context-agile objects. The clients of a context-agile object each have a direct reference to it, and no proxies are involved when making intra-app domain calls. Note that objects that derive from MarshalByRefObject are accessed via a proxy across app domains but are agile inside an app domain. Marshal-by-value objects are also context-agile.

The other type of object is called a context-bound object. Context-bound objects always execute in the same context. The designation and affinity of a context-bound object to a context is decided when the object is created and is fixed for the life of the object. To qualify as a context-bound object, the object must derive directly (or have one of its base classes derive) from the abstract class ContextBoundObject:

    public class MyClass : ContextBoundObject
    {...}

The client of a context-bound object never has a direct reference to it. Instead, the client always interacts with a context-bound object via a proxy. Because ContextBoundObject is derived from MarshalByRefObject, every context-bound object is also marshaled by reference across app domain boundaries. This makes perfect sense, because the context-bound object can't leave its context, let alone its app domain.

2. Component Services Types

.NET provides two kinds of component services: context-bound services and Enterprise Services. The context-bound services are available to any context-bound object. .NET offers only one such service: the synchronization domain. Using the Synchronization context attribute, a context-bound component gains automatic synchronization and lock sharing:

    [Synchronization]
    public class MyClass : ContextBoundObject
    {
       public MyClass( )
       {}
       public void DoSomething( )
       {}
    }

When you add the Synchronization attribute, .NET ensures that only one thread at a time is allowed to access the object, without requiring you to spend the effort implementing this functionality yourself, and you don't have to worry about deadlocks. Clients of such objects don't need to worry about synchronization either. Although this is the only context-bound service provided out-of-the-box, the .NET context is an extensible mechanism, and you can define your own custom context attributes for custom services and extensions.

The second kind of component services are .NET Enterprise Services (see the sidebar ".NET Enterprise Services"). Enterprise Services offer more than 20 component services covering an impressive array of domains, from transactions to loosely coupled events to web services. Enterprise Services are available only to classes derived from the class ServicedComponent. ServicedComponent is in turn derived from ContextBoundObject, so you can say that Enterprise Services are a specialization of context-bound services. If you develop a serviced component, you normally indicate which services the component relies on by using dedicated attributes.

    using System.EnterpriseServices;
     
    [ObjectPooling(MinPoolSize = 3,MaxPoolSize = 10)]
    public class MyComponent : ServicedComponent
    {...}

    using System.EnterpriseServices;
     
    [Transaction]
    [ObjectPooling(MinPoolSize = 3,MaxPoolSize = 10)]
    public class MyComponent : ServicedComponent
    {...}